Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix NoAccessLevelOnExtensionDeclaration to update members inside #if blocks. #969

Merged
merged 1 commit into from
Mar 25, 2025

Conversation

allevato
Copy link
Member

Fixes #966.

This rewrites the rule entirely to take advantage of the natural recursion of visiting the extension's children instead of trying to rewrite and replace the member list at the extension level.

I've tended to avoid the idea of writing stateful format rules like this, because pushing state down from a node to its children would normally require maintaining a stack of information. But in this case, the problem is a lot simpler because extensions can't be nested, so there's never more than one level of state to track.

@allevato allevato force-pushed the extension-access branch 2 times, most recently from 38ee56c to 7020673 Compare March 21, 2025 12:21
Copy link
Member

@ahoppen ahoppen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m sorry to disappoint you but nesting extensions is not a parser error. The following parsers fine

extension A {
  extension B {   
  }
}

Nested extensions only get diagnosed at type-checking time, so I think we do need to handle them…

@allevato
Copy link
Member Author

I’m sorry to disappoint you but nesting extensions is not a parser error. The following parsers fine

extension A {
  extension B {   
  }
}

Nested extensions only get diagnosed at type-checking time, so I think we do need to handle them…

Ugh, yeah, you're right.

Do you have a preference for how you'd like them handled? We could manage the stack and do the same thing for nested extensions that we would for top-level ones, or we could just ignore nested extensions because they're obviously broken.

@ahoppen
Copy link
Member

ahoppen commented Mar 21, 2025

I would just not walk into nested extensions. Leaving them as-is is probably the best thing we can do.

@allevato
Copy link
Member Author

I would just not walk into nested extensions. Leaving them as-is is probably the best thing we can do.

Updated. Instead of using a simple Optional for the state, I created my own State enum. It's technically isomorphic to an Optional (I thought I would need a third state for internal, but realized not because I would be skipping children in that case), but I think it still helps to clarify what's happening.

Copy link
Member

@ahoppen ahoppen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. One suggestion but it’s not blocking.

Comment on lines +102 to +104
public override func visit(_ node: ActorDeclSyntax) -> DeclSyntax {
return applyingAccessModifierIfNone(to: node)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of overriding all these functions, would it make sense to add a visitAny and call applyingAccessModifierIfNone from there?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just gave that a go and I think it ended up harder to follow. visitAny would have to do a check like "if the node isn't a decl, or if it's an ExtensionDecl or IfConfigDecl, return nil to allow the regular traversal", and it would also have to first call the super implementation because that's where we check if there's an applicable swift-format-ignore directive.

I think it's cleaner to just explicitly list out the decls we care about, even though it means having them listed in two places.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I thought that visitAny would have just checked if the node conforms to WithModifierSyntax. But maybe it’s not as easy as that.

@allevato allevato merged commit 88a8900 into swiftlang:main Mar 25, 2025
18 checks passed
@allevato allevato deleted the extension-access branch March 25, 2025 12:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

NoAccessLevelOnExtensionDeclaration doesn't apply access modifier on members guarded by #if
2 participants